Thanks for the PR @solsson.

Firstly, there's a pretty comprehensive history of the whole property/method assertion syntax here.

I must admit I'm a little dubious to include .to.be.defined, as we already have .to.exist (as you suggest). If this is simply to try to alleviate a need for () at every statement, I'd suggest just using the excellent chaining feature that chai has. I personally have linting rules to enforce (), but still happily use should - I'm just a little more careful about how I use it:

expect(foo).to.exist.and.equal(1);
expect(bar).to.exist.and.be.above(3);
expect(baz).to.exist.and.be.a('function');

Usually I find if I'm asserting something exists, I can easily make slightly more specific assertions about it too.

I'll mark this as more-discussion-needed to give you and others a chance to make a case for adding this, but my vote is no for this addition.

We do have the same issue that @feugy points out in #371. But we've continued to use chai expect style and with your advice on chaining we do get the advantages of (). Misspelling is only a problem with .be.undefined where chaining is useless.

These are the same assertions:

expect(foo).to.be.undefined
expect(foo).to.not.exist
expect(foo).to.equal(undefined);

Feel free to use the one with (), which jshint won't complain about.

I'm still not sold on .to.be.defined - I'm going to close this because of the reasons I mentioned above, but rest assured that I'm also putting thought into how we can alleviate the jshint problems, as this issue is still coming up a lot. For now, you should use dity-chai if you really want method style assertions.

Also @solsson, please don't let this put you off filing issues and making future PRs. It might be best to discuss your ideas as issues before turning into PRs though, as I'd hate you to feel as though your time is wasted.